Like many other electronic devices, users of mobile telephones are provided with the ability to freely change the date and time information on the telephone, as well the ability to alter time zone information. For this reason, a secure clock is used in time-based access control instead of a less-secure system clock.
When applications are making decisions whether to allow access to protected content, based for example on the Digital Rights Management (DRM) standard of Open Mobile Alliance (OMA), the applications need to know the secure time in order to do so. OMA DRM is a technology that allows control over consumption of various media objects, such as ring tones, images, etc., by mobile terminals. Control is exercised by supplementing each media object with a rights object that defines rules according to which media object is consumed. With some modification, this technology can also be applied to Java Mobile Information Device Protocol (MIDP) applications. If the device in question is fully compliant with the OMA DRM v1/v2 standard, for example, it is required that a secure time source be used when granting access to content restricted by interval constraints or constraints with start and/or end times.
However, when applications are making decisions whether to grant access to content based upon access rights information provided by content providers and operators, the applications can currently only rely on date and time information provided by the insecure system clock. Even if a secure clock providing a secure time was publicly available to every application, significant integration efforts would still be required for several applications in order to directly make use of such a secure time source. Additionally, showing the user two different clocks with different times would become difficult to absorb and comprehend by the user.
Although attempts have been made to overcome the above-identified shortcomings, each of these attempted solutions possess their own advantages. For example, the concept of a secure time source was introduced to platform applications, but it was not anticipated to have this feature be brought to the user's attention. For this reason, the secure time source was considered to be very confusing since applications would know the secure time and use it instead of system time, while content would stop working according to the secure time. Furthermore, in cases when the system clock is off, even by as few as a couple of minutes, the user experience might become relatively confusing. Additionally, integration of the secure clock to virtually every application would be very difficult to implement, and such an action would complicate the implementation of the overall system.